The Post-Script "copypage" operator causes the current page to be printed, then starts the next page with the same contents and composition state. The composition of the next page can continue normally or can close at any time, so the next page is the sum of all the postscript composition for both pages.
The "copypage" functionality is required for a complete emulation of the Post-Script language. The main utility for this operator is passing standardized Post-Script test packages. This copypage feature is also useful for debugging drivers and custom applications because this operator may be inserted at strategic points to isolate problems.
Previously, there were several different methods to accomplish Post-Script copypage functionality. These methods tended to be more complex to design, implement, and test than the value of the copypage feature. In some cases the implementation would not work for extensions such as duplexing.
In one Post-Script implementation, the method was to insert a special mark into the Display List when the copypage was parsed by the Post-Script Parser. The Display List was used with both the original and the next page. The difference was that rendering for the original page exited when the special mark was found, while it continued on for the next page. At first glance this approach seems simple. However, it requires sharing a resource between pages that was normally bound to one page. The implementation for this unnatural act required a considerable amount of complexity in design and implementation.
For example, consumable objects such as raster patches that normally had a one page lifetime required indeterminate lifetimes of two or more pages. This approach required reprocessing of the display lists and/or the use of reference counts on patches. A symptom that the single shared display lists were overly simplified was that the method broke down for duplex pages.
Another previous method for the implementation of copypage was to create and save a separate Display List copy for the next page, print the current page with the current Display List, then restore the saved Display List copy to continue the next page. This method also required substantial complexity to handle single-page consumable items such as raster graphics on multiple pages.
Both methods also required substantial complexity in order to synchronize caches such as the font cache. Adjustments for lifetimes had to be made that would manage lifetimes for the extra pages. In the first method discussed, the Display List must be parsed to determine the current characters and/or the font cache must be parsed and updated.